Description

The Standalone topbar's dark-mode toggle button has no accessible name and no announced state. Screen readers announce only "button" when the user lands on it, with no indication of what it controls or which mode is currently active. The lightbulb / lightbulb-off SVG that conveys state visually is not exposed to AT, so the visual signal has no AT equivalent.

This PR adds:

• aria-label="Dark mode"
• aria-pressed reflecting isDarkMode so AT users hear the toggle's current state.
• aria-hidden="true" on the inner SVG so caret-nav / browse-mode navigation doesn't surface the SVG path as a separate stop.

Motivation and Context

Part of the accessibility backlog. Detected by Tactual. WCAG 4.1.2 Name, Role, Value.

Refs #7350 (umbrella accessibility issue).

How Has This Been Tested?

• npm run test:unit — all suites pass (829 tests)

• npm run build — clean

• Computed-attribute snapshot via Playwright on the running build (master vs this branch):

  BEFORE (master)
    light state: aria-label=null    aria-pressed=null
    dark state:  aria-label=null    aria-pressed=null
    inner svg:   aria-hidden=null
  
  AFTER (this branch)
    light state: aria-label="Dark mode"   aria-pressed="false"
    dark state:  aria-label="Dark mode"   aria-pressed="true"
    inner svg:   aria-hidden="true"
  

• NVDA announcement (verified in Chrome):

  • BEFORE: "button" (no name, no state)
  • AFTER (light): "Dark mode, toggle button, not pressed"
  • AFTER (dark): "Dark mode, toggle button, pressed"

No visual change; this PR is ARIA-only.

Checklist

My PR contains...

• No code changes (src/ is unmodified: changes to documentation, CI, metadata, etc.)
• Dependency changes (any modification to dependencies in package.json)
• Bug fixes (non-breaking change which fixes an issue)
• Improvements (misc. changes to existing features)
• Features (non-breaking change which adds functionality)

My changes...

• are breaking changes to a public API (config options, System API, major UI change, etc).
• are breaking changes to a private API (Redux, component props, utility functions, etc.).
• are breaking changes to a developer API (npm script behavior changes, new dev system dependencies, etc).
• are not breaking changes.

Documentation

• My changes do not require a change to the project documentation.
• My changes require a change to the project documentation.
• If yes to above: I have updated the documentation accordingly.

Automated tests

• My changes can not or do not need to be tested.
• My changes can and should be tested by unit and/or integration tests.
• If yes to above: I have added tests to cover my changes.
• If yes to above: I have taken care to cover edge cases in my tests.
• All new and existing tests passed.